|
Group: Forum Members
Posts: 13,
Visits: 81
|
Hi Tim Not sure where to post this, so I'll put it here. Problem
I exported a flight log to GPX and imported it elsewhere. I noticed some very bizarre behaviour in the 'elsewhere' with particular respect to the aircraft's groundspeed. Cause
I traced the problem down the .flightlog files themselves. It wasn't hard to work out the format for the file. Regard the following: 26000,N513245.45 W0010622.95,191.4,93.8,324.5,239.3 29000,N513240.75 W0010623.55,177.1,95.4,361.9,301.7 30000,N513237.65 W0010622.85,172.0,95.0,378.3,344.2 31000,N513237.65 W0010622.85,167.1,96.6,395.7,344.2 31000,N513236.05 W0010622.20,167.1,96.6,413.4,367.2 32000,N513236.05 W0010622.20,167.1,96.9,413.4,367.2 34000,N513233.10 W0010620.25,153.2,97.0,448.5,424.5The first field is the number of milliseconds that have elapsed since the START= field at the file header. The rest is positional & velocity information. Consider lines 3-6. Between 30 and 31 seconds of flight, the aircraft apparently doesn't move (same position) despite the track and GS information suggesting differently. Then there is a second 31 second point logged at a different location, before a 32s point at the same location again. SolutionNot sure why this is occurring but clearly duplicate entries are creating issues not present when within the SD environment. I manually deleted the duplicate entries after manipulating a .flightlog in Excel and the results after exporting to GPX were better but not entirely fixed, probably because it isn't always the second row of duplicate data which is wrong. Also...
While investigating this, I realised why some of my flightlogs are from 2005 (!). The #START= field seems to use the system time of the recording unit to generate the timestamp. Why? We are using SD with GNSS navigation which is, in fundamental terms, a time-based navigation system!! Why not switch to using GPS time to generate the #START field? That way flightlogs will always show accurate dates & times even if, for example, I need to change the battery in my iPaq halfway through a days flying... #START=20050301110825
I fly something quick, but not time-machine quick... 
|
|
Group: Forum Members
Posts: 13,
Visits: 81
|
Thanks for the explanation. The timestamp thing, well, ok. Yet by saying that the software dumps simple, raw GPS data and then going on to say that since the signal can be lost it can't use GPS time to timestamp that data, I'm left confused. It suggests that it isn't dumping 'raw' GPS data at all, but Skydemon's interpretation of that data, which can be erroneous as we've seen. The bigger issue is not that it might 'skip' a dump, the issue is more that it has dumped reports for two different positions at exactly the same point in time (lines 4 and 5 in the list I gave) and then the same position in space at two different points in time (lines 5 and 6). Clearly the first is physically impossible and the second only possible in a hover so, hence, surely a bug...? Or, if this is truly by design, it's poor design. That was the gist of my post. Having exported a log from Skydemon into GPX format, the first record I get is: <trkpt lat="51.553030" lon="-1.099361"><ele>61.1124</ele><speed>16.925223</speed><time>2005-03-01T06:42:04Z</time></trkpt>2005? Only because I might have had to change my iPaq battery halfway through a long flying day. This record is only 'accurate' as long as the timestamp at the start of the .flightlog file it was exported from is correct. Since the latter is based on the system time of the recording unit, there is no integrity. Slightly poor show when you have a perfectly valid and accurate indicator of Zulu time at the hub of your navigation software; GNSS signals. Not only that, but the time shows in 'Z' format when it isn't. If the recording unit (iPaq, laptop, Ipad, whatever) is in a different timezone or has daylight savings time applied, the timestamp at the start of each SD log is wrong. So to then export it as a 'Z' time in a GPX file is not really legit. Memory-Map, meanwhile, may not warn about NOTAMS or give an ETA at the next waypoint, but at least it exports data with integrity. A similar GPX export gives a point for <trkpt lat="51.5534233093" lon="-1.0992983341"> <ele>67</ele> <time>2013-08-04T15:18:05Z</time> </trkpt> Seemingly a higher level of accuracy, a timestamp that was obtained from the GPS signal rather than the recording unit and is therefore immune to system time errors, timezone settings or daylight savings, as several years of my using it has demonstrated. I digress. Why not just have a .flightlog file which stores truly 'raw' GPS data; GPS time, GPS latitude, GPS longitude, GPS elevation, at intervals as frequent as you might like?
If SD loses a GPS signal, I don't see what useful data it could be logging from it anyway unless it starts doing some kind of ded-reckoning calculations.
|